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Call for Papers: Summer 1990 USENIX Conference 


Anaheim, CA, June 11-15,1990 

USENIX continues to seek papers describ¬ 
ing new and interesting work. However, the 
Summer 1990 Technical Conference also seeks 
to include papers that emphasize retrospec¬ 
tives, analyses of tradeoffs, and critical think¬ 
ing about where we are, how we got here, and 
why we’re here. Thus, the theme is: 

Beyond Mere Data: 

Perspective, Insight, Understanding. 

Some sessions will follow the normal 3- 
paper format, with questions following each 
talk. In other sessions, the speakers will form 
a panel, following the talks, first to compare 
approaches, and then to take questions from 
the audience. In some cases, other experts 
may be added to the panel to broaden the 
discussion. Especially desirable are sessions 
where several important different viewpoints 
are represented, and proposals for such ses¬ 
sions are welcome. 

Appropriate topics include, but are not 
limited to: 

Software release systems 
User interfaces, windowing, graphics 
Compilers, debuggers, tools, run-time issues 
File systems 
Distributed systems 
UNIX kernel approaches 
Fault-tolerancy, reliability, or security 
Computer architectures that stretch UNIX 

We will accept full papers, but require at 
least an abstract and outline, in a form that 
gives the committee confidence in the final pa¬ 
per. A submission should be 2-3 typewritten 
pages and include the following: 

1. Author names, addresses, telephone 
numbers, and E-mail addresses. 

2. Abstract: 100-300 words (half a page) to 
be included in the final paper. 

3. Outline: 1.5-2.5 pages, giving the major 
headings of the paper, plus a few sentences per 
section that give the major points that will be 
covered in that section in the final paper. 


The following is a sample outline, which is 
not necessarily appropriate for all papers, but 
which illustrates the important topics. The 
purpose of an outline should be to convince 
the committee that something interesting and 
important will be said in the final paper. 

1. Introduction 

• Background. 

Introduce the problem to be solved; 
why is it important? 

Reference previous work; make sure the 
committee knows the wheel is not being 
reinvented. 

2. How We Solved the Problem 

• More details on the problem and its 
issues. 

• Design decisions and tradeoffs, and why 
they were made. 

• Implementation issues. 

3. Evaluation 

• Data, on performance, effort required. 

• How well does it work? 

• What would we do differently? 

• If it failed, why? and what can we learn 
from it? 

4. Conclusion 

• Summarize the paper, emphasizing why it 
is important, and what was learned. 

5. References 

• List at least a few key references, prefer¬ 
ably to other people’s work. 

The final paper should retain the 100-300 
word abstract, include illustrations (where 
needed), and citations to relevant literature. 
Only previously unpublished submissions will 
be considered, although “retrospective” papers 
may describe work done years ago. Thinly- 
disguised product announcements are rarely 
accepted. Final papers should contain 8-12 
pages of single spaced typeset materials. All 
final papers must be submitted in a camera- 
ready format or electronic format (troff- ms if 
possible). Typewritten or dot-matrix output is 
not acceptable. For authors without access to 
a laser printer or typesetter, appropriate facili¬ 
ties will be provided by the program chair. 
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Please submit abstracts with outline and 
proposals for sessions as soon as possible, and 
mail one hard copy and one electronic copy to 
the addresses below. The final deadline for 
receipt of submissions is February 7, 1990. 
Abstracts received after this deadline will not 
be considered. Notification of acceptance or 
rejection will be made by March 9, 1990. Final 
camera-ready papers are due by April 17, 1990. 

John R. Mashey 

Anaheim USENIX Technical Program 
MIPS Computer Systems 
930 Arques Ave 
Sunnyvale, CA 94086 

Internet: anaheim@mips.com 
UUCP: uunetimips.comlanaheim 

Phone: (408) 991-0253 
FAX: (408) 720-9809 

Please include your physical and elec¬ 
tronic mail address in all correspondence. 


Program Committee: 

John R. Mashey, (Chair) 

MIPS Computer Systems 
Clem Cole 

Cole Computer Consulting 
Doug Comer 

Purdue University 
Tom Ferrin 

Univ. of CA - San Francisco 
James Gettys 

Digital Equipment Corp. 
Lori Grob 

Chorus Systems 
Douglas P. Kingston III 

Morgan Stanley & Co., Inc. 
Heinz Lycklama 

Interactive Systems Corp. 
M. Douglas Mcllroy 

AT&T Bell Laboratories 
Joe Moran 

Legato Systems, Inc. 

Pat Parseghian 

Princeton University 
Lawrence Rosier 
Hewlett Packard 
Bill Shannon 

Sun Microsystems, Inc. 
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C++ Conference 

Marriott Hotel, San Francisco, CA, April 9-11, 1990 


USENIX is pleased to announce its 1990 
C++ Conference. It will be devoted ex¬ 
clusively to C++ and will offer an intensive 
three day program bringing together in-depth 
tutorials along with Technical Sessions cover¬ 
ing a broad spectrum of work. 

April 9 - Full Day Tutorials 
Tutorial Program 
An Introduction To C++ 

Robert Murray, AT&T Bell Laboratories 

A survey of the main features of C++ 
(including features added in Version 2.0) will 
be presented, with some short examples on 
how to use the features effectively. Most use 
of C++ falls into one of three flavors: a better 
C, data abstraction, and object-oriented 
programming. We will examine these flavors, 
starting with the features and paradigms that 
are closest to C, and progressing to the more 
ambitious (and potentially more powerful) 
features. We’ll also discuss the relationship 
between ANSI C, C++ Version 1.2, and C++ 
Version 2.0. 

Effective Use of C++ 

Andrew Koenig, AT&T Bell Laboratories 

A review of the central concepts of C++, the 
ways in which the language supports those 
concepts, and a detailed tour through several 
complete programming examples. This tu¬ 
torial will emphasize “how to use it well” 
rather than “what the features are.” Attendees 
are presumed to be capable of looking up 
details of syntax and semantics themselves. 

A Tour of Cfront: Cfront 2.0 Internals 
Stanley Lippman, AT&T Bell Laboratories 

This tutorial surveys selected internal data 
structures and algorithms used by Cfront for 
the implementation of such C++ language 
features as multiple inheritance, virtual base 
classes, virtual functions, and the static initial¬ 
ization and deallocation of objects. We will 


attempt to make sense of the generated inter¬ 
mediate C code in light of these structures. 
Examples of both effective and ineffective cod¬ 
ing styles will be discussed. 

Half Day Tutorials 

Using C++ on the Macintosh 

Bill Gibbons, Consultant, & Ken Friedenbach, 
Cadence Design Systems 

Macintosh Programmer’s Workshop (MPW) 
C++ is an adaptation of the AT&T C++ 
Language Translation System version 2.0. 
This tutorial will provide information regard¬ 
ing the MPW C++ language, as well as infor¬ 
mation about libraries, debuggers, browsers, 
and other software development support tools 
on the Macintosh. Topics include: overview 
of MPW C++ language features, support for 
the Macintosh toolbox and operating system, 
support for the Macintosh memory model, and 
language support for MacApp. The tutorial 
will explain the development of sample Macin¬ 
tosh applications and MPW tools using C++, 
as well as covering useful programming 
techniques and common errors to avoid. 

Using C++ with MacApp 

Ken Friedenbach, Cadence Design Systems 

MacApp is an extensible Macintosh Applica¬ 
tion which simplifies the task of writing a fully 
functional Macintosh application. Macintosh 
Programmer’s Workshop (MPW) C++ includes 
features to support using C++ to develop 
MacApp applications. This tutorial will pro¬ 
vide information about using MPW C++ with 
MacApp to implement fully functional Macin¬ 
tosh applications. Topics include: C++ 
language support for MacApp and Object Pas¬ 
cal, overview of the MacApp libraries, sup¬ 
porting multiple documents and windows, us¬ 
ing the clipboard to support cut and paste, 
printing, and reading and writing document 
data. The tutorial will include sample applica¬ 
tion code, guidelines for creating building 
blocks to be shared between applications, and 
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advice for mixing MacApp classes with multi¬ 
ple inheritance classes. 

April 10 & 11 

Technical Sessions 

Full details regarding the Technical 
program will be available by mid-February. 
Please contact the USENIX Conference office. 

Submissions for papers closed Jan. 12,1990. 


Professional Development Seminars 


The USENIX Association has initiated a 
series of Professional Development Seminars 
in cities throughout the United States. The 
seminar program is a subset of the highly ac¬ 
claimed tutorial offerings presented at the 
Association’s semi-annual Conferences. It will 
be presented in major metropolitan areas that 
are not currently scheduled for one of the 
Conferences. 

The Seminar Program 

After a successful debut in Chicago, Oc¬ 
tober 30, 1989, the next program is scheduled 
for the Houston Marriott at the Astrodome, 
March 19, 1990. 

The tutorials being offered provide an in- 
depth look at three different areas: internals; 
networking; and software development. Atten¬ 
dees needing to expand their knowledge in any 
of these areas will benefit from the material 
presented by the instructors - all are experts in 
their respective fields. Enrollment is limited to 
150 people per tutorial to ensure a consistent 
level of interaction between the instructors and 
attendees. 


The tutorials being offered in Houston are: 

UNIX System V Release 4.0 Internals 
- An Introduction 
Steve Buroff & Mike Scheer, AT&T 

UNIX Network Programming 

Richard Stevens, Health Systems Interna¬ 
tional 

Software Development Using UNIX & C 
Rob Kolstad, Sun Microsystems 

For further information on the Houston 
Professional Development Seminar, please 
contact: 

USENIX Tutorial Office 
5398 Manhattan Circle 
Boulder, CO 80303 

(303) 499-2600 
(303) 499-2608 (FAX) 
johnd@usenix.oig 


6 


January/February 1990 





;login: 13:1 


Call for Papers: UNIX Security Workshop 

Marriott Hotel, Portland, OR, August 27-28,1990 


The Second UNIX Security Workshop is 
to be held in Portland, Oregon, on Monday 
and Tuesday, August 27 and 28, 1990. Matt 
Bishop will again be chairing this workshop. 
It will bring together researchers in computer 
security dealing with UNIX and system ad¬ 
ministrators trying to use UNIX in environ¬ 
ments where protection and security are of vi¬ 
tal importance. It is intended to provide an 
environment where researchers can discuss 
their latest results, where researchers and prac¬ 
titioners can discuss the applicability of those 
results to practical problems, and where 
system administrators can share their unique 
solutions and techniques for dealing with 
problems. The topics covered by this 
workshop include both theoretical topics and 
everyday problems. We expect each par¬ 
ticipant to present unique attributes of his/her 
environment and/or research and contribute a 
short (five minute) discussion (and paper) 
detailing some result or solution from their en¬ 
vironment or work. 

Some topics to be considered include: 

modeling the UNIX operating system 
theoretically 

password security (password file integrity, 
enforcing choice of a safe password, 
spotting and handling crackers) 
network security (problems arising from logins 
over an unprotected Ethernet, containing 
a break-in to one machine in a networked 
environment) 

security in a distributed system or 
environment 

file system security (auditing packages, security 
in an NFS environment) 
computer worms, viruses, and other 
phenomena 

new designs to obtain C-level (or better) 
certification 

making existing UNIX systems more secure, 
and locating and fixing UNIX security 
problems 

any other problem or contribution that 
participants make. 


Workshop Format 

This gathering will follow a “workshop” 
format rather than a “paper presentation” for¬ 
mat. Please submit a one or two page sum¬ 
mary describing a problem and, if you have 
one, a solution or if not, a possible approach 
or approaches which looked promising but 
failed (or which you have not yet tried). Also, 
be sure to include with your submission a set 
of five (or so) topics that you’d like to hear 
about. It is possible that some participants 
will not present their papers at this workshop. 

The workshop chairman will collate the 
papers to schedule sessions which have 
appropriate audiences. It is anticipated that 
some sessions will include all participants 
though others may require breaking into 
smaller groups. Send your submissions to the 
address below by May 22, 1990. 

For further information, contact: 

Matt Bishop 

Dept, of Mathematics and Computer Science 
Bradley Hall 
Dartmouth College 
Hanover, NH 03755 

(603) 646-3267 

decvax!dartvax!Matt.Bishop 

Matt.Bishop@dartmouth.edu 
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Call for Papers: Mach Workshop 
Radisson Hotel, Burlington, VT, October 4-5,1990 


The use of Mach in what has traditionally 
been the UNIX community is growing as 
DARPA and OSF increase their Mach-related 
activities and more vendors are supporting 
Mach on a variety of platforms. Because 
Mach itself is changing rapidly and there 
hasn’t been any convenient mechanism for 
communication among developers, the 
USENIX Association is pleased to sponsor its 
first Mach workshop, in which researchers, 
vendors, and users can share results of Mach- 
related development work and status reports 
on work-in-progress. 

The workshop will be oriented towards 
those who have actually worked with Mach or 
have done Mach-based applications develop¬ 
ment, and will not be tutorial in nature. The 
program will consist largely of refereed papers 
and panels. Abstracts of 350-700 words 
should be sent to the program chair at the ad¬ 
dress below (those submitting hardcopy 


abstracts should send five copies). The dead¬ 
line for submissions is June 22, 1990. All sub¬ 
missions will be acknowledged. Authors will be 
notified by July 20, 1990, and full papers will 
be required by August 27, 1990. 

For further information about the 
workshop, contact the program chair: 

Melinda Shore 
mt Xinu 

2560 Ninth St., Suite 312 
Berkeley, CA 94710 

(415) 644-0146 
shore@mtxinu.com 

Program Committee: 

Alan Langerman, Encore Computer Corporation 
Douglas Orr, Camegie-Mellon University 
Homayoon Tajalli, Trusted Information Sys. 
Avadis Tevanian, NeXT, Inc. 


Request for Proposals to Chair the Large Installation 
Systems Administration Workshop (LISA) 


The USENIX Association is seeking 
proposals from people interested in chairing its 
fourth LISA workshop, to be held sometime in 
the Fall of 1990. 

We are seeking an energetic person with the 
following qualifications: 

• Good administrative skills 

• Extensive experience in the administration 
of large installation systems 

• Good public speaking skills 

• Knowledge of what are the timely and 
appropriate topics in the field 

• Ability to solicit good panel members and 
appropriate speakers 

• Attendance at one previous LISA 
workshop 

Proposals should be brief (one page) and might 
include the following: 

• Statement of Purpose (e.g., why should we 
have another one?) 

• Form of submissions: abstracts, extended 
abstracts or full papers? 


• Format (e.g., two days of technical ses¬ 
sions, panel sessions, etc.) 

• List of topics to be addressed 

• Special features: such as having tutorials, 
BOFs 

• List of potential program committee 
members and/or a co-chair* 

• Brief biography 

Proposals are subject to approval by the 
board of directors. Details concerning the 
schedule, site and call for papers will be 
worked out with the Association after the ap¬ 
pointment of the chair has been made. 

Proposals are due: February 15, 1990. 

Please address all inquiries and proposals 
to the Association’s Executive Director, Ellie 
Young (ellie@usenix.org). 


* While most USENIX workshops have an individual chair, 
proposals requesting a co-chair and/or small program com¬ 
mittee are welcome. 
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Call for Papers: EUUG Conference 


October 22-26, 1990, Nice, France 

The Autumn 1990 European UNIX 
systems User Group Technical Conference will 
be held October 22-26, 1990, at the Nice 
Acropolis, Nice, France. Technical tutorials 
on UNIX and closely related subjects will be 
held on October 22-23, followed by the three 
day conference with a commercial exhibition. 

Call for Papers 

The EUUG invites papers from those 
wishing to present their work. Full papers or 
extended abstracts must be submitted. All 
submitted papers will be refereed and judged 
with respect to their quality, originality, and 
relevance. 

Suggested subject areas include, but are 
not limited to: 

• Software Management for large projects 

Configuration Management 
Maintenance Management 
Update and Release control 

• OSI and OSI application on a UNIX platform 

• System Administration in a Hetrogeneous 
environment 

• Security and Audit 

Secure UNIX 

Securing existing systems 

• UNIX in non-English speaking environments 

• User Interface Management Systems 

Submissions from students are particularly 
encouraged under the EUUG Student 
Encouragement Scheme, details of which are 
available from the EUUG Secretariat. 

Important Dates 

Abstract deadline 
Acceptance notification 
Final paper received 
Student Grant Applications 
deadline 

Method of Submission 

Full papers or extended abstracts must be 
submitted by post to the EUUG Secretariat 
and, if possible, in electronic form to 
euug-nice@eu.net. All submissions will be ack¬ 
nowledged by return of post. 


Guidance to Authors 

A copy of the EUUG guidance to Authors 
will be sent automatically to everybody that 
submits a paper. It will also be printed in the 
Spring edition of the EUUG newsletter. 

Tutorial Solicitation 

Tutorials are an important part of the 
EUUG’s biannual events providing detailed 
coverage of a number of topics. Past tutorials 
have been taught by leading experts. 

We are keen to provide classes to all lev¬ 
els. Those interested in offering a tutorial 
should contact the EUUG Tutorial Executive 
as soon as possible. 

Additional Information 

We will be pleased to provide advice to 
potential speakers, and can be contacted at the 
addresses below. 

If you wish receive further information 
about this and future EUUG events, please 
write, or send electronic mail, to the 
Secretariat. 

EUUG Secretariat 
Owles Hall 
Owles Lane 

Buntingford, Herts SG9 9PL UK 

Phone: (+44) 763 73039 
Fax: (+44) 763 73255 

Email: euug@eu.net 

Conference & Tutorial Executive 
Neil Todd 
GiD Ltd 

Email: neil@gid.co.uk 

Program Chair 
Johan Helsingius 
OY Penetron Ab 
Email: julf@fuug.fi 

Program Committee 

Pierre Louise Neumann INRIA France 

Dr. Elod Knuth MTA SZTAKI, Hungary 

Daniel Klein CMU, USA 


April 30, 1990 
May 10, 1990 
June 30, 1990 

Sept. 1, 1990 
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Call for Papers: UKUUG Conference 

“UNIX - The Legend Evolves” London, England, July 9-13,1990 


The UKUUG Summer 1990 Technical 
Conference will take place at the^Royal Lan¬ 
caster Hotel in London on July 11-13, 
preceded by two days of advanced tutorials be¬ 
ginning on Monday, July 9. The three day 
conference offers presentations by world 
renowned exponents of UNIX related systems 
supported by “work in progress” and “poster” 
sessions. 

Program and Speakers 

Brian Kernighan will speak about the 
progress which has been made in the develop¬ 
ment of programming environments, 
languages, tools, and even “methodologies,” 
discussing how past experiences will influence 
their future evolution. Ken Thompson, Rob 
Pike, and Dave Presotto have been conducting 
research into a successor to UNIX entitled 
“Plan 9 from Bell Labs.” The result is a novel 
and innovative distributed system which runs 
counter to the popular trend in computing en¬ 
vironments, namely workstations connected by 
local area networks. Each will speak on his 
contribution to the proposal of a new system 
based on clusters of file servers and execute 
servers connected by high speed networks. 

Other noteworthy presenters include Jon 
Bentley, Doug Comer, Piers Dick-Lauder, 
Dennis Ritchie, Stu Feldman, James Gosling, 
Mike Karels, Kirk McKusick, and Andy 
Tanenbaum. 

Call for Papers 

Technical papers are sought in all areas of 
UNIX-related research and development, 
which includes work associated with program¬ 
ming languages like C and C++. Accepted pa¬ 
pers will be published in the conference 
proceedings and presented during the three 
days of technical sessions. 

Of particular interest, but not confined to 
this area alone, are new and interesting sub¬ 
missions about distributed environments: .file 


systems, data bases, execution and load 
balancing, kernels, windowing systems, etc. 
Also welcome are papers concerning tools, “lit¬ 
tle languages,” networks, security, system ad¬ 
ministration, and standards. 

Method of Submission and Important Dates 

Extended abstracts of between two and 
four pages in length are invited describing the 
nature of the work along with a summary of 
results and conclusions. All abstracts must be 
submitted to the Program Director who is also 
willing to provide advice to potential speakers. 
High quality original work will be regarded 
much more favorably than re-runs of previous 
papers. Submissions from students are 
encouraged and will be particularly favored. 

Receipt of Extended Abstracts: Jan. 26,1990 
Acceptance Notifications: Jan. 31,1990 

Final Paper Due: April 6,1990 

Solicitation for Other Contributions 

The one day advanced tutorials play an 
important role in UKUUG’s activities and so 
experts are encouraged to discuss topics and 
subject matter with the Program Director. For 
the first time at a UKUUG conference, a “work 
in progress” session will be held where 10-15 
minute slots are available, with priority being 
given to reports of student projects and 
research activity. For those preferring one-to- 
one contact, “poster” sessions are available in 
the terminal room next to the auditorium for 
technical sessions. 

Contact: 

Program Director 

Sunil K. Das 

City University London 

Computer Science Department 

Northampton Square EC IV 0HB UK 

(01) 253-4399 x3725 
sunil@cs.city.ac. uk 
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Long-Term Calendar of UNIX Events* 


1990 Feb 14 
1990 Mar 5-6 
1990 Mar 26-29 
1990 Mar 26-30 
1990 Apr 9 
1990 Apr 9-11 
1990 Apr 23-27 
1990 Apr 23-27 
1990 May 7-11 
1990 May 17 
1990 May 30-Jun 1 
1990 Jun 11-15 
1990 Jun 11-15 
1990 Jul 9-11 
1990 Jul 11-13 
1990 Jul 16-20 
1990 Aug 27-28 
1990 Sep 25-28 
1990 Oct 3-5 
1990 Oct 4-5 
1990 Oct 8-12 
1990 Oct 22-26 
1990 Oct 22-26 
1990 Oct 31-Nov 1 
1990 Nov? 

1990 Nov 5-9 
1990 Nov 8 
1990 Nov 14-16 
1990 Nov 15 
1990 Nov 15-16 
1990 Dec 4-5 
1990 Dec 10-14 


UKUUG Sys. Admin. Workshop 

X3J11 

DECUS 

AFUU 

POSIX APP Workshop 

USENIX C++ Conference 

EUUG 

IEEE 1003 

DECUS 

U & Parallel Systems, NLUUG 

UNIX/90 

USENIX 

ISO WG15 (POSIX) 

15th JUS Symposium 

UKUUG 

IEEE 1003 

* Security 
AUUG 

Intemat’l S of MHS, IFIP WG 6.5 
*Mach 

InterOp 90 ACE 
EUUG 
IEEE 1003 
UNIX Expo 

* Software Devel. Environments 
Computer Communication Conf. 
Open Systems, NLUUG 
UNIX EXPO ’90 UniForum 
POSIX APP Workshop 

16th JUS Symposium 
JUS UNIX Fair ’90 
DECUS 


Inst, of Ed, London, UK 

New York, NY 

Vasteras, Sweden 

Paris, France 

NIST; Gaithersburg, MD 

San Francisco, CA 

Munich, Germany 

Salt Lake City, UT 

New Orleans, LA 

Ede, Netherlands 

/usr/group/cdn; Toronto, Ont. 

Marriott Hotel, Anaheim, CA 

Paris, France 

Tokyo, Japan 

London, UK 

Danvers, MA 

Portland, OR 

World Congress Centre, Melbourne, Aust. 

Zurich, Switzerland 

Burlington, VT 

San Jose, CA 

Nice, France 

Seattle, WA 

New York, NY 

West Coast, USA 

ICCC; New Delhi, India 

Ede, Netherlands 

Stockholm, Sweden 

NIST; Gaithersburg, MD 

Osaka, Japan 

Tokyo, Japan 

Las Vegas, NV 


1991 Jan 7-11 
1991 Jan 21-25 
1991 Jan 22-25 
1991 Feb 
1991 Feb 18-22 
1991 May 
1991 May 6-10 
1991 May 20-24 
1991 Jun 10-14 
1991 Sep 16-20 
1991 Dec 9-13 


IEEE 1003 

USENIX 

UniForum 

UNIX in Government 

DECUS 

UNIX 8x/etc 

DECUS 

EUUG 

USENIX 

EUUG 

DECUS 


Florida 

Grand Kempinski, Dallas, TX 
Infomart, Dallas, TX 
Ottawa, Ont. 

Ottawa, Ont. 

/usr/group/cdn; Toronto, Ont. 
Atlanta, GA 
Tromso, Norway 
Opryland, Nashville, TN 
Budapest, Hungary 
Anaheim, CA 


1992 Jan 20-24 USENIX 

1992 Jan 21-24 UniForum 

1992 Spring EUUG 

1992 May 4-8 DECUS 

1992 Jun 8-12 USENIX 

1992 Autumn EUUG 


Hilton Square, San Francisco, CA 
Moscone Center, San Francisco, CA 
Jersey, UK 
Atlanta, GA 

Marriott, San Antonio, TX 
Amsterdam, Netherlands 


t Compiled with the assistance of Alain Williams of the EUUG, John Quarterman of Texas Internet Consulting and Susanne 
Smith of Windsound Consulting. 

* USENIX Workshops 
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Speakers Bureau 


The USENIX Association is seeking volunteers to participate in a Speakers Bureau. 
The purpose of the Speakers Bureau is twofold: to provide a forum for people with exper¬ 
tise in various areas of UNIX to share that knowledge with others; and, to provide a source 
of speakers for educational groups (high schools, colleges, universities, local user groups) 
who could discuss a variety of UNIX-related topics in a colloquium-type setting. 

We would like the Speakers Bureau to have a local flavor where the volunteers and in¬ 
terested groups draw from within the local/regional community. In cases where round trip 
travel of greater than 50 miles is involved, USENIX would provide a mileage allowance. 

Before you discard this idea, thinking you are too busy, please consider volunteering to 
speak just once or twice during the year. We are sure you will find this a rewarding experi¬ 
ence and a great service to the audience. 

When a request for a speaker is received, the Speakers Bureau will try to match the re¬ 
quirements with a particular volunteer’s expertise. If you are contacted, and cannot speak, 
please feel free to decline. We want you to accept only those invitations which you truly 
want to do. 

Should you decide to lend your expertise to this project, please fill out the Information 
Sheet and return it as soon as possible. We would like to promote this concept, but need a 
collection of speakers before we can announce its existence to potentially interested groups. 

If you do not wish to volunteer, but know of someone within the UNIX community 
who might be interested in participating, please fill out the relevant part of the Information 
Sheet, and we shall contact that person directly. If you know of a group that would benefit 
from some of the resources that may become available, please let us know. 


John L. Donnelly 
Coordinator 

USENIX Speakers Bureau 
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Speakers Bureau Information Sheet 

Name: _ Title: 

Organization: _ 

Address: _ 


Phone (work): _ (home): _ 

email address: _ 

Do you have any logistical limitations where/when you can speak? 

Geographical area: _ Day of week: 

Length of time: _ Time of day: 

Do you have any group preferences (high schools, colleges, user groups)? 


How often would you make yourself available to speak? 


What are your particular areas of expertise? 


Give a brief description of yourself (educational background, current position, previous speaking ex¬ 
perience, etc.) 


Do you know of any other people who might be interested in being involved in the Speakers Bureau 
(in any capacity - give name[s], phone number[s])? 


Are you interested in using the resources of the Speakers Bureau for your group or organization? If 
so, what topics would you be interested in? 


Please return this form to: 

Speakers Bureau 303-499-2600 

USENIX Association 303-499-2608 (FAX) 

5398 Manhattan Circle, Suite 201 johnd@usenix.org 

Boulder, CO 80303 
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UUCP Project Draws Strong Response 


As discussed in the last issue of ; login:, 
USENIX is studying uucp to see whether we 
can help promote better communication, in a 
literal sense, by activities which might range 
from standardization up to a possible spon¬ 
sored implementation. 

We have received more than 30 mail 
messages on this topic from Europe, Australia, 
and the U.S. Many of these were cheers and 
bravos, and most requested further informa¬ 
tion. A number were from people who were 
actively working on uucp itself, or on programs 
that were similar to, or “better” than uucp. In 
particular, there was relevant work going on at 
AT&T, GNU, in Australia with ACSnet, in 
Great Britain with UKUUCP, and at Prime 
Computer in Australia, with MYL. A program 
called PP, which supports numerous protocols, 
is in the beta stage in Great Britain, and will 
be “openly available.” Finally, Rick Adams, 
has been doing advanced CPR on uucp for 
years to keep uunet running smoothly, and has 
suggested that he might make this available. 

There appear to be three major decision 
areas (battlegrounds?). One is technical - what 
do we want, given that we can’t have every¬ 
thing. Some people wrote and suggested that 
using anything other than streams and TLI was 
senseless and short-sighted; others wrote that 
the use of streams and TLI would lock us out 
of a large number of smaller and older 
machines, and should be avoided at all cost. I 
personally would like to have some graphic 


(X-ish) administration interface so I can add a 
phone number without screwing up the 
company-wide system for days; but this limits 
our communication scope. 

The next set of decisions has to do with 
the distribution of the system; will it be free, 
or merely cheap. The majority think it should 
be distributed in source code; a vocal minority 
paint a picture of a totally snarled net created 
by enthusiastic hackery by hundreds of mon¬ 
keys at their terminals. Some think it should 
be licensed, others totally free. 

The related problem is how to get it done; 
should USENIX endorse, support, initiate, or 
purchase the work? There are a lot of touchy 
issues here, including what the cost would be, 
how it would be recovered (hold on to your 
wallets, members!), and how USENIX would 
ensure that it got its money’s worth (ever try 
to manage a software project with volunteers?). 

The USENIX board of directors will be 
taking this topic up again at its meeting in 
Washington, D.C. We shall report on the out¬ 
come from that meeting in the next issue of 
;login:. I haven’t really done justice in this 
summary to some of the lengthy, thoughtful 
comments that we have received; thank you 
for the encouragement and the information. 
Further comments and suggestions can be sent 
to scj@usenix.org or discussed with other 
USENIX board members. 

Steve Johnson 
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Book Reviews 

UNIX System Software Readings 
AT&T UNIX Pacific Co., Ltd. 

(Englewood Cliffs, NJ: Prentice-Hall, 1988, 
ISBN 0-13-938358-1) 

Reviewed by George W. Leach 

AT&T Paradyne 

This book records the presentations made 
by six invited speakers from AT&T at a 
seminar held in Japan in the summer of 1986. 
The seminar was sponsored by AT&T UNIX 
Pacific (ATTUP) in order to disseminate infor¬ 
mation concerning new technologies for 
System V Release 3.0 to the Asian/Pacific 
UNIX community. The contents of the book 
are as follows: 

1. Larry L. Crume, Introduction 

2. Brian W. Kemighan, Beyond UNIX 
(Keynote Speech) 

3. Gilbert J. McGrath, Streams Technology 

4. Laurence M. Brown, Networking Architec¬ 
ture & Protocol 

5. Arthur L. Sabsevitz, Distributed UNIX 
System - Remote File Sharing 

6. Gary L. Lindgren, Directions in Interna¬ 
tionalization 

7. David G. Korn, The Shell - Past, Present, 
and Future 

A great deal of the material presented here 
has not been readily available to the general 
public. For example, Kemighan’s presentation 
covers the activities of the Computer Science 
Research Center at Bell Labs in Murray Hill. 
It has been several years since information has 
become available on much of the UNIX-related 
work going on there. 1,2 However, some of the 
current focus is shifting away from Research 
UNIX and the Blit towards Plan 9 and the 
Gnot. 3,4,5 

The papers by McGrath, Brown, and 
Sabsevitz describe the System V approaches to 
networking and distribution. Once again, very 
little has been written about Streams and the 


Transport Level Interface (TLI) for networking 
with System V. 6,7 Descriptions of RFS are 
hard to come by as well. 8 For someone new to 
System V these papers make an excellent, 
albeit brief, introduction to these facilities. 

Some of the internationalization support 
that is described in Lindgren’s paper will be 
incorporated into SVR4. At the time of the 
seminar, the Japanese Application Environ¬ 
ment (JAE) 1.0 was available from ATTUP. 
However, today it is not even the current pro¬ 
duct offering, which will be superceded by 
SVR4. Still, the background material on inter¬ 
nationalization is quite relevant and makes the 
paper worth reading. In fact, the existence of 
this paper in this collection is what attracted 
my attention to the book. 

David Korn’s paper on the UNIX Shell 
provides a nice history of the development of 
everyone’s favorite command interpreter as 
well as an overview of its functionality. And, 
of course, the Korn Shell is featured in the 
paper. There are some comparisons of the 
capabilities of the Bourne, C, and Korn Shells 
as well, but they are minimal. 

The viewgraphs from the seminar presen¬ 
tations are included as figures for each paper. 
This is a nice touch. Often folks will request 
copies of viewgraphs from a presenter despite 
the existence of a paper in the proceedings. 

Overall, my impression of this collection 
is that for the experienced UNIX programmer 
the material is too elementary. The topic cov¬ 
erage is mostly at a conceptual level and of a 
tutorial nature. Furthermore, the bulk of the 
material is specific to System V. BSD fans will 
not be interested. And finally, the presenta¬ 
tions are based upon a release of System V 
that is about to be eclipsed. Some of the areas 
covered in the book are due for some new 
features, for example an out-of-band com¬ 
munications capability will be added to 
Streams. 9 

There is, however, some worthwhile 
material in this collection for UNIX folks of all 
persuasions. The paper by Kemighan is prob¬ 
ably the most concise description of the work 
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that the folks in Murray Hill have been 
involved in over the past several years. The 
paper on internationalization does present a 
nice overview of the problems involved with 
working on software with an eye towards the 
world marketplace. And David Korn’s paper 
presents a unique perspective in the command 
interpreter arena. The papers are compact and 
to the point, much like the book (182 pages). 
And the list price of $21.95 won’t break your 
budget. 
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Elements of Computer Music 
By F. Richard Moore 

Prentice-Hall (1990) 546 pages 
Foreword by Max Mathews 

Reviewed by Mike Hawley 

MIT Media Lab 

In the spectrum of “Elements” books over 
the centuries, Moore’s is rather far from the 
slim Strunk & White or Kemighan & Plauger 
end, and pushing decidedly in the direction of 
Euclid (13 volumes). Computer music is a 
highly synthetic field - making good music 
with computers necessarily requires com¬ 
petence in programming (of all kinds, includ¬ 
ing systems, numerical algorithms, and inter¬ 
faces), mathematics, signal processing (with an 
audio bent), perhaps acoustics, probably 
psychology, and, from time to time, possibly 
even music. Considering all that, TECM is 
remarkably concise, yet still touches on a 
wealth of fine points. Because computing is a 
profession of mine, and music (including 
academic computer music) a consuming avoca¬ 
tion, I tend to read books of these kinds more 
for new tidbits than old examples. But the 
book covers a balance of topics that should 
resonate well with novices, amateurs, and 
head-banging die-hard computer music 
groupies: 

Introduction (Musical Data and Process; Musi¬ 
cal Thought; Composing; Performing; 
Instruments; Rooms; Listening; 
Disciplinary Context; Prerequisites); 

Digital Audio (Sound Representations; Sound 
Digitization; Spectrum Measurements; 
Digital Filters; Summary); 

Instruments (Representing Instruments; 
cmusic; Additive Synthesis; Subtractive 
Synthesis and Physical Models; Nonlinear 
Synthesis; Summary) 

Rooms (Concert Halls; Spatial Hearing; Early 
Echo Response; Reverberation; Sound 
Spatialization; Other Issues; Summary) 
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Composing (Computer-Mediated Composition; 
Music Representations; Random 
Numbers; Random Sieves; Markov 
Processes; Noise, Filters, Random 
Numbers, and Probability; Compositional 
Algorithms) 

Appendices - Mathematics; Units of Measure; 
Tuning; CMUSIC 

Index 

Computer music has been attached to 
(some would say mired in) the domain of sig¬ 
nal processing for years, so it’s not surprising 
that the middle three chapters (digital audio, 
instruments, signal processing) involve this 
sort of theory and its applications and imple¬ 
mentations. In fact, the book actually contains 
a good bit of the signal processing that every 
liberal-minded person ought to know and 
might almost make a workable introductory 
text for that field. There is a nice perspective 
on the streams of work done in the field, and 
extensive examples in the “cmusic” language 
(a dialect of C with add-ons for music and sig¬ 
nal processing). For novices, the fact that so 
much working example code is presented 
through C and cmusic is likely to be a boon - 
so long as the book comes with a diskette, 
which it apparently does not. Moreover, a 
book about music without audio illustrations 
is like an architecture book without pictures of 
buildings (or a Kama Sutra without ...). There 
seems to be no demo record with this book. It 
is an expensive undertaking - if not an out- 
and-out financial loss - to print a computer 


music book, but an attached recording, partic¬ 
ularly if it contained some demos by Prince of 
sampling synthesis applications or artificial 
ambience, say, would not only perk up the 
content, but might even boost the sale if it 
contained a new song. In fact, although the 
book does a nice service for the field, I suspect 
and hope that in five years, if not less, it will 
be preferable to embody this kind of survey in 
a computer ware, with running examples. My 
guess is that the advent of media-rich publish¬ 
ing systems, combined with the recent 
dramatic shift of attention away from signal 
processing and more towards content process¬ 
ing (e.g., MIDI), will make this text seem a bit 
quaint by 2000 A.D. 

Readers who would prefer to chaw on the 
gritty papers that populate the field can survey 
the Computer Music Journal over the years, or 
perhaps dive into a collection like “Founda¬ 
tions of Computer Music” (Curtis Roads and 
John Strawn, eds., MIT Press, 1985), which 
high-pass filters some of the esoterica. 
Although “great” computer music is tough to 
find, the field is definitely not short on printed 
matter. These disclaimers aside, though, 
Moore’s book is nevertheless as clear a survey 
as one could wish for. He is, as Mathews 
points out in the foreword, not only a techni¬ 
cal founder, but a fine teacher and writer. But 
perhaps better than that, he is also a bona-fide 
UNIX hacker. Many readers of .login: will 
enjoy tracking some of the familiar systems 
trails into somewhat new territory. 
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1989 USENIX Membership Survey 


In May 1989 the Executive office created a survey to gather information from the 
membership to learn more about who you are and what your membership needs are. The 
survey was mailed to 1,325 individual members. We received 498 responses - a whopping 
37% rate of return! 

Your feedback is useful to us. You want more technical articles in ;login:, more articles 
in Computing Systems, you raved about the C++ and Systems Administration Workshops; 
and you want more focus on networking. 

One of our charters in 1990 is to turn your recommendations into a reality. We 
appreciate your responses and look forward to a continuing dialogue. 

Here is a more detailed review of your answers to the open-ended questions and a 
graphic overview of the entire survey. 

What changes would you like to see in ;login:l 

More technical material 

Articles on trends in the industry 

A tips and hints/question and answer column 

What changes would you like to see in Computing Systems ? 

A volume devoted to a particular topic 

Articles that elaborate on the papers from conferences 

More articles that include graphics/illustrations 

More how/to applied articles 

More issues! 

Of the technical conferences you attended, which were the best? 

Of the 89 who answered this question: 

34 for San Francisco 
15 for Dallas 

9 each for Phoenix, San Diego, Portland and Atlanta 

Balance spread among Toronto, Salt Lake City, Denver and D.C. 

Of the workshops you attended which were the best? 

Overwhelmingly: C++ and Systems Adminstration 

Please list any topics you consider suitable for future USENIX workshops. 

There were many responses. The most frequestly mentioned were: 

Networking concerns - management and security 

OSI and UNIX 

Standards 
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X Windows 

Distributed/Multiprocessor Systems 
Mach 

Please list any projects (like UUNET or Face Saver) in which the Association might invest. 
(Some of these have been accomplished by USENIX or UUNET.) 

Most of the respondents were enthusiastic about UUNET and Face Saver, 
but had very few new ideas to offer. Here are a few: 

Have all the USENIX papers online 
Tutorials by mail/video 
Software portability guidelines 
An anonymous ftp site for USENIX sources 
Regional tutorials 

Funding for a complete rewrite of the news software 

An information retrieval system which could access contents of UUNET, 

News, FTP archives, publicly funded R&D efforts, etc. 

Literature database related to the computing industry - focusing on 
UNIX-related subjects 

Portability checker for C source code and a library of portable, reusable 
software libraries and programs 
More research in efficient news distribution 
A central site for public domain software in source form 

We would appreciate any suggestions you might have that can be incorporated into future 
surveys. Please contact the Executive Director ( ellie@usenix.org). 

-EY 
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1989 USENIX Membership Survey 


USENIX Information 


Do you read ;login:7 

Always. 

-—Sometimes— 


-Never 

If you do, please remark on its content: 

Worthless 

Average 


Excellent 

Technical content (articles, reviews) 

0.1— 

.2 . 

-3- 

.4 

Information regarding workshops & conferences 

0-1— 

.2 . 

-3- 

.—4 

Information regarding user groups 

0.1—- 

.2 . 

-3- 

.4 

What changes would you like to see in ;login:7 

Do you read Computing Systems 7 

Always- 

—Sometimes— 


-Never 

If you do, please remark on its content: 

Worthless 

Average 


Excellent 

Technical content (articles, reviews) 

0-.1— 

. 2 . 

—3- 

.4 

Format 

0-.1— 

. 2 - 

-3- 

.4 

What changes would you like to see in Computing Systems 7 

In 1987, the Association distributed two tapes containing 70MB of 
software derived from net.sources and mod.sources; in 1988 a 
tape of C++ software was produced. Should the Association 
continue to produce and distribute software tapes? 


Yes- 


.No 


Persona! Information 


Are you employed by: 

or are you: 


□ a business or corporation 

□ self-employed 


□ an educational institution 

□ a full-time student 


□ a government agency 

□ other 


□ a nonprofit organization (other than educational) 



□ a research facility 



Approximately how many are in your organization? 

-„ 


Are you: 



□ an executive or senior manager 

□ a programmer or technical staff member 

□ a dean or department chair 

□ a consultant or self-employed 


□ a project leader or senior programmer 

□ a student 


□ a professor or instructor 

□ other 


Have you completed: 



□ a doctorate 

□ a baccalaureate 


□ a masters 

□ college without a degree 


□ some graduate work 

□ high school 


How many years have you been a USENIX member? _ 

— 


Are you a member of: 

How many years have you been using UNIX?_ 

□ ACM □ other professional organizations 



□ IEEE 

How old are you? 


□ /usr/group 




Are you □ male or 

□ female 

What is your annual salary or income? 



— <£i nir 
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If you have attended any USENIX conference or workshop in the past 




three years, please give your general assessment: 

Unsatisfactory— 

-—Fair— 

.Good 

□ Denver Technical Conference 1986 

□ 

□ 

□ 

□ Atlanta Technical Conference 1986 

□ 

□ 

□ 

□ Monterey Graphics Workshop 1986 

□ 

□ 

□ 

□ Washington Technical Conference 1987 

□ 

□ 

□ 

□ Philadelphia Systems Administrators’ Workshop 1987 

□ 

□ 

□ 

□ Phoenix Technical Conference 1987 

□ 

□ 

□ 

□ Cambridge Graphics Workshop 1987 

□ 

□ 

□ 

□ Berkeley POSIX Workshop 1987 

□ 

□ 

□ 

□ Santa Fe C++ Workshop 1987 

□ 

□ 

□ 

□ Dallas Technical Conference 1988 

□ 

□ 

□ 

□ IEEE/USENIX Real-Time Workshop 1988 

□ 

□ 

□ 

□ San Francisco Technical Conference 1988 

□ 

□ 

□ 

□ Portland Security Workshop 1988 

□ 

□ 

□ 

□ Pittsburgh Supercomputing Workshop 1988 

□ 

□ 

□ 1 

□ Denver C++ Conference 1988 

□ 

□ 

□ 

□ Monterey Systems Administrators’ Workshop 1988 

□ 

□ 

□ 

□ San Diego Technical Conference 1988 

□ 

□ 

□ 

Of the technical conferences you attended, which were the best? 




Of the workshops you attended, which were the best? 




Please list any topics you consider suitable for future USENIX 




workshops. 




Do you prefer concurrent Winter conferences with /usr/group? 

Yes- 

—No- 

—Don’t Care 

Please list any projects (like UUNET or Face Saver) in which the 




Association might wisely invest. 





Thank you for completing this year’s survey. 
Your (nosey) Association staff 


Please return this survey to: 

USENIX Association 
2560 Ninth Street 
Berkeley, CA 94710 
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1989 USENIX Membership Survey 
"Do you read ;login:?" 

4% 7% 



B No Response 
B Always read ;login: 

_i Sometimes read ;login: 

□ Never read ;login: 


1989 USENIX Membership Survey 
Rating of ;login: Content 
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50 
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ID Excellent 


□ 

5 Average 

■ 

□ Worthless 
I No Response 


Technical 


Workshops & Conferences 


User Groups 
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1989 USENIX Membership Survey 
"Do you read Computing Systems?" 



38% 


H No Response 

■ Always read Computing Systems 

□ Sometimes read Computing Systems 

□ Never read Computing Systems 


1989 USENIX Membership Survey 
Rating of Computing Systems 


N 

u 

m 

b 

e 

r 

o 

f 

R 

e 

s 

P 

0 

n 

d 

e 

n 

t 

s 


500 

450 

400 

350 

300 

250 

200 

150 

100 

50 

0 



Technical Content Format 


3D Excellent 

□ 

EH Average 


□ Worthless 
I No Response 
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1989 USENIX Membership Survey 
"Should the Association continue to produce tapes?" 

5% 8% 



87% 


■ No Response 

■ Yes 
□ No 


1989 USENIX Membership Survey 
"Are you employed by:" 


No Response 
Business or Corporation 
Educational Institution 
Government Agency 
Nonprofit Organization 
Research Facility 
Self—employed 
Full—time Student 
Other 



0 50 100 150 200 250 300 

Number of Respondents 
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1989 USENIX Membership Survey 
"How many in your organization?" 



29% 


■ No Response 

□ <10 

■ <100 
■ <1,000 
□ <10,000 
B <100,000 
(D >=100,000 


1989 USENIX Membership Survey 
"Are you:" 


No Response 
Executive or Senior Manager 

Dean or Department Chair 

Project Leader or Senior 
Programmer 

Professor or Instructor 
Programmer or Technical Staff 
Consultant or Self—employed 
Student 
Other 



Number of Respondents 
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1989 USENIX Membership Survey 
"Have you completed:" 


No Response 

Doctorate 

Masters 

Some Graduate Work 

Baccalaureate 

College without a Degree 
High School 



0 20 40 60 80 100 120 140 160 180 200 

Number of Respondents 


1989 USENIX Membership Survey 
"How many years a member of USENIX?" 

4 % 1 % 5 % 
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1989 USENIX Membership Survey 
"How many years using UNIX?" 



■ 

No Response 

□ 

<1 

■ 

<2 

■ 

<3 

□ 

<5 
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<7 

ID 

<10 


<12 

S3 

>=12 


1989 USENIX Membership Survey 
"Are you a member of:" 
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1989 USENIX Membership Survey 
"Are you:" 


10% 


5 % 



85 % 


■ No Response 
□ Male 
BS Female 
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1989 USENIX Membership Survey 
"Annual Salary or Income" 



26% 


■ 

No Response 

□ 

under $10K 

■ 

$10K 

IS 

$20 K 

□ 

o 

CO 

m 

$50 K 


$70K 


$100K 

1 _ 

over $100K 
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1989 USENIX Membership Survey 
"Do you prefer concurrent Winter conferences with /usr/group?" 


36 % 



■ No Response 
H Yes 
& No 

□ Don't Care 
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Denver Technical Conference 1986 

Atlanta Technical Conference 1986 

Monterey Graphics Workshop 1966 

Washington Technical Conference 1987 

Philadelphia Systems Administrators’ 
Workshop 1987 

Phoenix Technical Conference 1987 

Cambridge Graphics Workshop 1987 

Berkeley POSIX Workshop 1987 

Santa Fe C++ Workshop 1987 

Dallas Technical Conference 1988 

IEEE/USENIX Real-Time Workshop 
1966 

San Francisco Technical Conference 
1988 

Portland Security Workshop 1988 

Pittsburgh Supercomputing Workshop 
1988 

Denver C++ Conference 1988 

Monterey Systems Administrators' 
Workshop 1988 

San Diego Technical Conference 1989 


1989 USENIX Membership Survey 
"Attendees assess conferences and workshops” 


137 


TTTTTT1 8 


153 


m 


no 


IIIIIIIIIIIIIIIIIII 20 


(1 

DD3 


mnimiiiiiis 


156 


|1 

1)2 

|1 

IE3 


157 


II 

]1 


110 


[iniiniiiiiiiiiiiiiiii]27 


II 

m 


iiiiimiiimiiiiniii' 


160 


195 


■ 2 

mini 7 


110 


II 

m 

■ 3 

■ 2 


]1 


11 


lllllllllllllllllllllllllllllllllll ae 


190 


■ Unsatisfactory 
ill Fair 

■ Good 


Number of Respondents 


January/February 1990 


33 


;login: 15:1 


An Update on UNIX and C Standards Activity 

Jeffrey S. Haemer 

Report Editor, USENIX Standards Watchdog Committee 


Report on IEEE 1003.0: POSIX Guide 

Kevin Lewis <klewis@gucci.enet.dec.com> 
reports on the October 16-20, 1989 meeting in 
Brussels, Belgium: 

Dot Zero’s mission in Brussels was to step 
back and review where the group had been 
and where we needed to go. We learned that 
we are headed in the right basic direction but 
still need to make some course corrections. 

There are two major contributors to this 
state of affairs. First, an honest review of the 
pre-Brussels document reveals that it still has 
significant holes. Also, its format is hard to 
follow. I must admit that it felt good to see 
unanimous consent on both the need to reor¬ 
ganize the document and on a new format. It 
does a co-chair’s heart good to see two such 
rare events occur concurrently. The reformat¬ 
ting of the draft guide will be complete by the 
January meeting in New Orleans. The group 
will then review components of the document 
that are sufficiently complete section-by-section 
and line-by-line. 

Second, Dot Zero faces a problem that is 
becoming widespread in 1003 and TCOS-SS: 
a serious dilution of effort. Little did Dot 
Zero realize, when it recommended the forma¬ 
tion of a group to address a windows standard 
(now 1201), that we would lose people who 
had been shepherding key components of the 
Dot Zero guide. The new efforts have left us 
with no one to cover networking, graphics, or 
windows, though it’s possible that new folks in 
these areas will join us in New Orleans. 
[Editor’s note: Listen to this man. What are 
your ideas about open systems in these areas? 
If you have something useful to contribute, 
please contact someone on Dot Zero : Kevin. 
Don’t wait until it’s too late and then com¬ 
plain about the result.] 

Regarding internationalization (for which 
the current buzzword is “118N,” because there 
are eighteen letters between the T and the 
‘N’): 


Everyone who attended the I18N study 
group meeting sponsored by Dot Zero found it 
interesting when the question regarding the 
group’s future was posed. All those present 
tacitly agreed that it would not be in the best 
interests of I18N efforts for this study group to 
become a full-fledged working group. This 
study group would best serve the industry as a 
forum for issue flagellation, soap-boxing, and 
formation of proposals to the appropriate 
accredited bodies. At the appropriate time, 
the I18N group will declare that its time is up. 

When the question of identifying the 
major contributors to the I18N efforts arose, I 
noticed an effort of OSF to remain at arm’s 
distance from X/Open. In light of OSF’s 
membership in X/Open, this might signify its 
desire to maintain its own identity. 

That’s enough negatives. Is there an up¬ 
side to all this? Yes, absolutely. We have a 
reorganized document that will ease and 
streamline the review process. We now have 
the eyes of the industry and the press looking 
over our shoulders, eager to read our guide. 
We are reaching the point where fear of per¬ 
sonal and professional embarrassment is 
motivating those who have an interest in this 
effort’s succeeding. These will help us meet 
our goal of preparing a draft for review and 
comment by ISO by the Fall of 1990. 

Report on IEEE 1003.1: 

System Services Interface 

Mark Doran <md@inset.co.uk> reports on the 
October 16-20, 1989 meeting in Brussels, Bel¬ 
gium: 

PI003.1 is now a full-use standard, so 
interest in attending the working group has 
waned somewhat. Attendance didn’t get above 
fifteen or so all week and was nearer half a 
dozen most of the time. Even so, this was a 
bit low by comparison with recent meetings. 
So where was everyone? 
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[Editor’s note - Notice that this is larger 
than the attendance at typical meetings of, for 
example, dot nine. “Low attendance” is 
relative. Author’s additional note - And that’s 
the frightening thing; standards are being esta¬ 
blished by as few as half a dozen individuals. 
This cannot be representative or balanced. 
Scary stuff, “...as we take you on a journey, 
into the Standards Zone...”] 

We thought that meeting in Brussels was 
going to further the cause of international par¬ 
ticipation in the POSIX process. Several peo¬ 
ple I would normally expect to see, didn’t 
show; Europe may be too far from home for a 
lot of the regulars. Unfortunately, I didn’t see 
more than two or three Europeans (whom I 
would not normally expect to see at POSIX) 
all week either. Oh well, I’m sure it was a 
good idea really... So what did those that 
showed get up to? 

ISO 9945. [Editor’s note - ISO 9945 is, 
roughly, the ISO standard engendered by and 
corresponding to the POSIX work.] 

It looks like 9945 is going to be split up 
into three major pieces, the first of which is 
founded upon the IEEE P1003.1-1988 stan¬ 
dard. This piece is likely to include all the 
other system interfaces as well (notably, the 
real time stuff from PI003.4). The other two 
pieces will be based around utilities and 
system administration. 

The basic IS9945-1:1989 will be just the 
same as the regular, ugly-green, dot-one book - 
well almost. ISO has yet another documenta¬ 
tion format, and the book will have to be 
squeezed to fit it. This one doesn’t allow line 
numbers either. We are assured that making 
the changes is not a major problem, but the 
working group has still requested a new 
disclaimer telling readers that all mistakes are 
the fault of ISO! 

P1003.1a. [Editor’s note - This document 
(supplement A) is supposed to contain 
clarifications of and corrections to P 1003.1- 
1988, but no substantive changes.] 

The meeting discussed resolution issues 
from the first ballot. Highlights included: 

• the decision to withdraw the cuseridQ 
interface; its loss will not be sadly mourned 


since one can use other interfaces to do the 
same job better. 

• the addition of a new type name ssi ze_t 
to represent signed size.t values; this has all 
sorts of uses - for example, in the prototype 
for read(). Currently, the parameter specifying 
the number of bytes to be readQ is given as a 
size.t, but readQ has been specified to return 
an int, which may not be large enough to 
hold a size.t character count. Moreover, 
read() may return -1 for failure; or the number 
of characters read if the call was successful. 

The recirculation ballot happened between 
November 10-20, 1989; if you care but didn’t 
know that already, it doesn’t matter because 
you (and many others, I suspect) have missed 
your chance. This all seems a bit fast but it 
does mean that P1003.1a will hit an ISO, six- 
month, letter-ballot window. 

Transparent File Access. Isn’t this a PI003.8 
problem? Yes, but the chairperson of the TFA 
committee came to talk about TFA semantics 
as they relate to P1003.1. 

The crux of the matter is that the six TFA 
folks seem to have decided that standardizing 
NFS will do nicely for TFA. Their chairper¬ 
son wonders whether the rest of the world (or, 
more accurately, the balloting group for a TFA 
standard) will agree. 

The answer from the dot one folks appears 
to be definitely not (thank goodness)! There 
appear to be several arguments against NFS as 
the TFA standard from dot one. These 
include: 

• It is impossible to maintain full dot one 
semantics over a network using NFS. Con¬ 
sider the last-close semantics, for example, 
which can only be preserved over a network 
using a connection-oriented protocol, which 
NFS is not. 

• Transparent File Access should be 
transparent; NFS isn’t. It is possible for opera¬ 
tions that are logically sound to fail because of 
network timeouts. 

• NFS is a de facto standard; why should it 
get an official rubber stamp? 

This appears to be a hot topic that many 
groups may have an interest in, so there will 
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be an “out-of-hours” meeting on TFA at the 
New Orleans POSIX - [Editor’s note - If you 
do care, we suggest either writing directly to 
the TFA chair, Jason Zions 
<jason@hpcndr.cnd.hp.com>, or posting your 
opinions to comp.std.unix.] 

Language-Independent Specification. It seems 
to have been decided that POSIX API stan¬ 
dards should be written in a language- 
independent form, i.e. not expressed in C- 
language constructs. 

My initial reaction was one of horror, but 
then someone pointed out that C is not the 
only program m i n g language in the known 
universe. This I have to concede, along with 
the idea that bindings to POSIX APIs in other 
lang uag es may not be such a bad idea after all. 
Indeed work is well underway to produce 
FORTRAN and Ada bindings. 

But now it seems we have to express 
POSIX in a language-independent way. When 
you come to write the next set of actual 
language bindings, the semantics won’t be 
clouded with language-dependent stuff; the 
idea is that you won’t have to understand C in 
all its “glory” to write new language bindings. 

So what will the language-independent 
specifications look like? Will I be able to 
understand those? The current proposal 
doesn’t look like anything I recognize at all. 
Yes, that’s right, we have to learn a whole 
NEW language (sigh). Why not use a more 
formal specification language that a few people 
know? (Like ASN. 1 for example, which 
PI003.7 has decided to use.) Better yet, why 
not use constrained English? Since the 
FORTRAN and Ada bindings folks have 
managed without the aid of language- 
independent specifications, why can’t everyone 
else? Is there more to this than a glorified job 
creation scheme? (“Wanted: expert in POSIX 
‘language-independent’ language...”) If there is, 
do we have to invent a new wheel to get the 
job done? 

As you can tell, my opinion of this effort 
is somewhat jaundiced. Perhaps, I have 
missed the point. Maybe so, but if I have, I 
feel sure that some kind soul will be only too 
happy to correct me in “flaming” detail. 


Messaging. The UniForum internationaliza¬ 
tion (I18N) folks brought forward a proposal 
for a messaging facility to be included in 
P1003.1b. The working group decided that it 
needs some more work but will go into the 
next draft. 

[Editor’s note - The problem being solved 
here is that internationalized applications store 
all user-visible strings in external files, so that 
vendors and users can change the language of 
an application without recompiling it. The 
UniForum I18N group is proposing a standard 
format for those files.] 

P1003.1b. Work on production of the second 
supplement is still at a formative stage. The 
group is still accepting formal proposals for 
functionality to add to the document. Where 
PI003.la has been drawn up as a purely 
corrective instrument, P1003.1b may add new 
functionality. Among the interesting things 
currently included are these: 

• The messaging proposal described above. 

• A set of interfaces to provide symbolic 
links. The basic idea is that lstat(), readlink() 
and symlinkQ operate on the link, and all 
other interfaces operate on the linked-to file. 

Rationale will be added to explain that it is a 
unique directory, which is the parent directory 
in the same physical file system. This means 
that cd does not go back across symlinks to the 
directory you came from. 

This is the same as the semantics on my Sun. 
For example: 

(sunset) 33 % pwd 

/usr/spare/ins.MC68020/md/train 

(sunset) 34 % Is -Id ,/MR_C+ + 

lrwxrwxrwx 1 root 32 Sep 30 1988 MR_C+ + 

-> /usr/sunset/md/c+ +/trainset/c+ +/ 

(sunset) 35 % cd MR_C+ + 

(sunset) 36 % pwd 
/usr/sunset/md/c+ +/trainset/c+ + 

(sunset) 37 % cd .. 

(sunset) 38 % pwd 
/usr/sunset/md/c+ +/trainset 

The rationale is meant to help keep 
readers aware of what’s really written in the 
standard and help them avoid misinterpreting 
it along lines of their own potential misconcep¬ 
tions. 
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• PI003.lb used to have two descriptions of 
Data Interchange formats. Now it has only 
one. The working group picked the one that 
remains because it more closely resembles 
existing standards in the area. In particular, 
the surviving proposal refers to X3.27. 

Report on IEEE 1003.4: 

Real-time Extensions 

John Gertwagen <jag@laidbak> reports on the 
November 13-17, 1989 meeting in Milpitas, 
CA: 

Background 

The PI003.4 Real-time Working Group, 
began as the /usr/group technical committee 
on real-time extensions. About two years ago, 
it was chartered by the IEEE to develop 
minimum extensions to POSIX to support 
real-time applications. Over time its scope has 
expanded, and PI003.4 is now more a set of 
general interfaces that extend P1003.1 than a 
specifically real-time standard. Its current 
work is intended to support not only real-time, 
but also database, transaction processing, Ada 
runtime, and networking environments. The 
group is trying to stay consistent with both the 
rest of POSIX and other common practice out¬ 
side the real-time domain. 

The work is moving quickly. Though we 
have only been working for two years, we are 
now on Draft 9 of the proposed standard, and 
expect to go out for ballot before the end of 
the year. To help keep up this aggressive 
schedule, PI003.4 made only a token appear¬ 
ance at the official PI003 meeting in Brussels. 
The goal of the Milpitas meeting was to get the 
draft standard ready for balloting. 

Meeting Summary 

Most of the interface proposals are now 
relatively mature, so there was a lot of i- 
dotting and t-crossing, and (fortunately) little 
substantive change. The “performance 
metrics” sections of several interface chapters 
still need attention, but there has been little 
initiative in the group to address them, so it 
looks like the issues will get resolved during 
balloting. 


The biggest piece of substantive work was 
a failed attempt to make the recently intro¬ 
duced threads proposal clean enough to get 
into the ballot. The stumbling block is a con¬ 
troversy over how to deal with signals. 

There are really two, related problems: 
how to send traditional UNIX/POSIX signals 
to a multi-threaded process, and how to asyn¬ 
chronously interrupt a thread. 

Four options have been suggested: 
delivering signals to a (somehow) privileged 
thread, per Draft 8; delivering a signal to 
whichever thread is unlucky enough to run 
next, a la Mach; delivering the signal to each 
thread that declares an interest; and ducking 
the issue by leaving signal semantics 
undefined. 

We haven’t been able to decide among the 
options yet; the working group is now split 
evenly. About half think signal semantics 
should follow the principle of least surprise, 
and be fully extended to threads. The other 
half think each signal should be delivered to a 
single thread, and there should be a separate, 
explicit mechanism to let threads communi¬ 
cate with one another. 

Personally, I think the full semantics of 
process signals is extra baggage in the “light¬ 
weight” context of threads. I favor delivering 
signals to a privileged thread - either the 
“first” thread or a designated “agent” - and 
providing a separate, lightweight interface for 
asynchronously interrupting threads. On the 
other hand, I would be happy to see threads 
signal one another in a way that looks, syntac¬ 
tically and semantically, like inter-process sig¬ 
nals. In fact, I think the early, simpler ver¬ 
sions of signalQ look a lot like what’s needed 
(around V6 or so). I don’t care whether the 
implementation of “process” and “thread” sig¬ 
nals is the same underneath or not. That deci¬ 
sion should be left to the vendor. 

Directions 

Draft 9 of PI003.4 is being readied for 
ballot as this is being written and should be 
distributed by mid-December. With a little 
luck, balloting will be over by the Summer 
of’90. 
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Threads is the biggest area of interest in 
continued work. The threads chapter will be 
an appendix to Draft 9 and the balloting group 
will be asked to comment on the threads 
proposal as if it were being balloted. Unless 
there is a significant write-in effort, the threads 
interface will probably be treated as a new 
work item for PI003.4. Then, if the outstand¬ 
ing issues can be resolved expediently, threads 
could go to ballot as early as April ’90. 

With the real-time interfaces defined, it 
looks like the next task of this group will be to 
create one or more Real-time Application Por¬ 
tability Profiles (RAPPs?) that define how to 
use the interfaces in important real-time appli¬ 
cation models. Agreeing on the application 
models may be harder than agreeing on the 
interfaces, but we’ll see. 

Report on IEEE 1003.6: 

Security Extensions 

Ana Maria de Alvare <anamaria@lll- 
lcc.llnl.gov> reports on the October 16-20, 
1989 meeting in Brussels, Belgium: 

The security working group worked the 
full week, discussing the draft. The meeting’s 
primary goal was to approve the current draft 
for distribution to the international working 
groups. It was presented, at the EEC, to new 
members of the group from the European 
countries. 

TRUSIX 

A representative from TRUSIX, Charles 
Testa, gave a progress report on TRUSIX. 
[Editor’s note - TRUSIX is an organization 
sponsored by the National computer security 
center (NCSC), developing a secure UNIX 
model. The participants are a number of ven¬ 
dors developing secure UNIX implementa¬ 
tions.] Their modeling subcommittee has 
nearly completed a formal model describing 
the UNIX file system. They have accepted the 
“Ina Jo” model to describe Trusted UNIX 
System Interfaces. This model revolves 
around a MAC-read criterion, MAC-writes and 
a DAC constraint, and consists of simple 
security properties, confinement properties, 
and discretionary security properties represen¬ 
tative of the Bell-LaPadula model. The 


TRUSIX ACL Rationale and Working Exam¬ 
ple Document has been approved by the 
NCSC and is being reviewed for publication 
under NCSC security publications. 

One topic of interest to all security readers 
is prevention and/or detection of covert chan¬ 
nels. TRUSIX is planning to include this 
under the Audit Rationale Document, which 
will include examples of typical covert chan¬ 
nels and their implications. Issues such as 
bandwidth evaluation will be addressed by a 
separate white paper. 

POSIX Conformance Testing 

A representative from 1003.3, the POSIX 
Conformance Testing group, presented 
1003.3’s goal - to establish a series of 
specifications for testing the different POSIX 
standards. Although they have written the 
pseudo-code to test the conformance of a 
system to 1003.1, they feel they lack the staff 
and expertise to produce such tests for all the 
1003 groups. Given this, their current plan is 
to draw upon each group for expertise and 
background knowledge of the subject at hand, 
and join those skills with their testing skills to 
produce a test bed for each 1003 standard. 

Their ultimate goal is to allow testing of 
all elements of an open system for POSIX con¬ 
formance by defining common test methods, 
which can then be implemented by private 
industries as test suites. They explained how 
to list the assertions, how to classify them, and 
what information they will need to produce a 
test method for 1003.6. 

One factor mentioned was that the 
description has to address a single unit of 
behavior expected of a conformant system at a 
time. This implies dissecting interfaces into 
separate groups of assertions and generating 
assertions for both semantic and syntactic 
descriptions. 

Discretionary Access Control (DAC) 

The group focused on polishing and 
adding information to the draft. It was sug¬ 
gested the standard shouldn’t define the 
behavior of chmod when old programs are 
being executed with the DAC mechanism. 
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It was noted that the current proposed 
Access Control List (ACL) might not be fully 
compatible with the current behavior of a 
chmod call. With the current, old-style 
behavior, when chmod is used to change 
owner, group and/or other permissions, the 
changed permissions represent the access 
modes of the file. In the current proposal for 
ACL, a chmod will provide the old behavior 
for the “owner” and “other” fields, but the 
“group” field permissions as set by chmod and 
shown by stat, wouldn’t represent the actual 
access permissions of the group associated 
with that file; instead, it’s a summary of all 
access permissions included under the ACL list 
for group entries. In other words, it would 
represent the maximum permissions allowed 
to the group entries included in the ACL list. 

Some participants argued that chmod 
should be replaced by other system calls in a 
system conforming to 1003.6. In other words, 
if your system were to conform to 1003.6 the 
behavior of chmod would be unspecified and 
unpredictable. 

I disagree. Although defining the behavior 
of chmod might restrict some implementations 
of ACLs, having a well-defined chmod 
behavior will provide backward compatibility 
and ease porting old programs to 1003.6- 
conformant systems. Otherwise old programs 
will have to be ported to platforms with 
system-dependent representations of chmod 
and stat information. 

It was also proposed that the ACL list 
should allow entry types like timestamping. 
This would allow a policy that is more 
restrictive than the DOD orange-book policy 
to provide more granularity of file access. 

Mandatory Access Control (MAC) 

Kevin Murphy, of British Telecom, 
presented his views on electronic mail label 
usage and proposed that such a mechanism 
should be used as part of the standard. The 
electronic mail security labels consist of a 
generic format that includes four major com¬ 
ponents: security policy id, security classifica¬ 
tion, privacy mask, and security categories. 
This approach to labels is implemented on 
X.400 security services. One clear advantage 
of using such a format for labels is that it 


maximizes the potential synergy between 
operating system and electronic mail labels. 

Chris Hughes from ICL presented British 
views on MAC information labels. Its main 
characteristics are these: object creation ini¬ 
tializes the label, the label is implementation 
defined and changed by the owner, and the 
label is not used for access control. Chris 
proposed that the standard should provide a 
get/set mechanism for the object information 
label, and a way to merge and translate infor¬ 
mation labels, but should not standardize the 
labels’ contents. 

Information labels are useful because they 
provide added information on particular 
objects. We concluded that information labels 
should be in the scope of MAC as part of the 
standard, and requested that MITRE provide a 
presentation on information label use at the 
next meeting. 

Privileges 

The whole group heard a presentation of 
the internal draft of the privileges document. 
We decided that the wording had problems. 
The draft interface description is too obscure 
and needs a simpler description of privilege 
interfaces, before it can be included in the 
1003.6 draft document. 

Although the group argued considerably 
about the wording, they seemed to agree on 
the concepts. The main points are that 
privilege is associated with a process and 
privilege attributes can be attached to files. 

I do not think I should burden the reader 
with the brainstorming ideas of the privilege 
group until a firmer position is taken at the 
next meeting. One thing I can say is that the 
process privilege concepts described in my last 
report (permitted, inheritable and effective) 
still stand, and a file still has three types of 
privilege attributes. 

Audit 

Kevin Brady from AT&T and Doug 
Steves from IBM presented a combined 
proposal, produced by them and Henry Hall 
from DEC, on how to define audit interfaces 
for 1003.6. Their proposal was meant to 
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contest the current audit stand, led by Olin 
Sibert from Oxford Systems. 

The current audit definition is based on 
the token concept and on a pure procedural 
interface. In the procedural interface all data 
manipulation of the audit record is performed 
by function calls, with data passed explicitly 
through function parameters. Although this 
sounds attractive and clear, in practice it 
requires many function calls. 

Another major point of controversy was 
the audit trail format. In Olin’s proposal, 
conversion cost is minimal because writes and 
reads require an explicit specification of the 
format wanted. In Kevin, Doug, and Henry’s 
proposal the conversion function is set to one 
of three conventional formats: little endian, 
big endian, or XDR. In other words, the 
information is stored in machine-dependent 
format while Olin’s chooses a uniform format 
for all information stored. 

One last contested feature was the ability 
to rewind audit trail information when viewing 
it. Kevin, Doug, and Henry’s proposal does 
not allow a rewind, since information is 
manipulated at the data structure level. 

Because of the heated discussion of pro¬ 
cedural versus data structure interfaces for 
POSIX, both proposals will be formally 
written out, removed from the draft, and 
presented in the next meeting for a final vote. 

Report on IEEE 1003.8/1: POSIX 
Transparent File Access 

An anonymous correspondent reports on the 
July 10-14, 1989 meeting, in San Jose, Califor¬ 
nia: 

[Editor’s note - Though this report came 
in substantially later than the other July 
reports, I think it’s still useful, provocative, 
and well worth reading.] 

Overview of New 1003.8 Developments 

1. All standards produced by POSIX com¬ 
mittees (with the exception of language¬ 
binding standards like 1003.5 and 1003.9) 
must be specified in a language-independent 
fashion, and must include at least one 
language-specific binding. Since PI003 will 


not have guidelines and rules for constructing 
a language-independent specification before 
April 1990, no POSIX networking group can 
possibly ballot a document before July 1990. 
“Mock” ballots (aka trial-use ballots) are 
unaffected by this, but their usefulness will be 
diminished. 

2. Two new POSIX Networking working 
groups either have submitted or will soon sub¬ 
mit PARs to begin work, bringing the total 
number of POSIX Networking working groups 
to six. These new groups are the Name Space 
and Directory Services Interface and the 
X.400 Mail Gateway Interface. [Editor’s note 
- The SEC approved the PAR for the former, 
but decided that the latter transcends POSIX, 
and recommended that the IEEE form a 
separate, numbered group, analogous to 1003 
or 1201, to handle X.400. See below.] 

3. Due to the rules governing IEEE and 
IEEE-TCOS standards activities, as well as the 
logistical nightmare six sub-working groups 
cause, the hierarchical structure of the PI003.8 
POSIX networking committee will be flattened 
out, with each current sub-group submitting 
PARs to cover their current work. Coordina¬ 
tion will be provided by a “POSIX Network¬ 
ing Steering Committee,” made up of the 
chairs and vice-chairs of each networking- 
related working group and the current chair 
and vice-chair of 1003.8. [Editor’s note - This 
is still being debated by the SEC.] 

4. Since each of the 1003.8 sub-groups will 
be submitting separate PARs, the PI003 
Sponsor’s Executive Committee (SEC) is tak¬ 
ing the opportunity to evaluate the degree to 
which each PAR is intended to represent a 
part of the “POSIX Environment” or is a 
component which has no relationship to the 
rest of POSIX and should, hence, stand alone. 
The result of this is that several of the 1003.8 
sub-groups may be issued project numbers out¬ 
side of the PI003 family. There is some 
precedent for this; the XI1 interface group was 
assigned project number PI201 for just this 
reason. 

Activity in the TFA Subgroup, P1003.8/1 

The group is making slow but steady 
progress towards the goals of a fully-specified 
programmatic interface for networked file 
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access and the semantics and suggested syntax 
for administrative interfaces for such a 
functionality. The group is dominated by a 
faction, apparently led by Sun Microsystems, 
with a goal of ensuring that NFS, in some 
form, is a sufficient mechanism to provide the 
service required by the “full TFA” interface. 
The balance of the committee is composed of 
people who simply want a standard they can 
use as an acquisition tool. 

Achievements 

* Enough consensus and material was 
obtained to permit development of a first draft 
of the programmatic interface part of the 
specification; this draft should be complete in 
time for the second mailing, due out on Sep¬ 
tember 8. 

* Liaison activities with 1003.7 (System 
Administration) continued; .7 indicated that 
all of the options for the TFA mount / 
unmount model were, in fact, of use in 
administering such a system. They also agreed 
that they owned responsibility for all file¬ 
system commands not completely unique in 
function to TFA, and that they would pursue 
input from the TFA group when the time was 
right. 

* Further progress was made on identifying 
status and usage information which must be 
obtainable from the provider of a TFA service. 

Problem Areas 

1. Representation in the group is unbal¬ 
anced; there is, as of this time [Editor’s note - 
July, ’89], no substantial representation of the 
“stateful” side of the semantic issues. The 
chairman has, so far, been unsuccessful in 
encouraging a more balanced group viewpoint 
so representation from the stateful camp has 
been solicited (with minimal success) for 
future meetings. 

2. Several “grey areas” in the semantics of 
IEEE 1003.1-1988 have been identified by the 
TFA group over the last several months. The 
suggested “fixes” have been slanted in a way 
that would let the TFA interface avoid relaxing 
1003.1 semantics while permitting a stateless 
implementation of the TFA service; i.e. rather 
than strengthening 1003.1 to define the actual 
behavior of a single stand-alone system, the 


proposals have been so weak that they under¬ 
constrain single-system behavior. It appears 
that the majority of the 1003.1 committee will 
not approve of this approach, and will require 
the “fix” to be of the proper strength to 
correctly specify single-system behavior. 

Let me give an example. The original 1003.1 
standard is silent on the issue of when the 
effects of a write are visible to a subsequent 
read of the same byte of the file. If process A 
writes byte 123 of file foo, then process B does 
a read of byte 123 of file foo, at what point is 
B guaranteed to see the byte A wrote? 

Immediately? If so, stateless solutions employ¬ 
ing read caches fail; if process B is remote on 
system “bsys” and reading the file via NFS, 
byte 123 might come out of the file cache on 
bsys and not from the file cache on the system 
where A lives. 

Immediately if A and B are on the same 
system, and at some implementation-defined 
time otherwise? This requires 1003.1 to define 
what it means by “the same system,” and 
doesn’t adequately address multi-processor sin¬ 
gle systems with “interesting” caches. It also 
means a truly portable application that is 
interested in running in a distributed environ¬ 
ment can never know when the byte written by 
A is visible to B. 

Only in the presence of byte locking? In other 
words, A locks byte 123, writes it, unlocks it; if 
B then locks and reads 123, it is guaranteed to 
see what A wrote. Not a bad solution, but it 
breaks existing applications and in fact is a 
relaxation of the intended semantics of 1003.1. 

Basically, the “intent” developing in 1003.1 is 
that the effect of the write must be seen 
immediately by any other process with that file 
open, without regard to process location, 
without recourse to 0_SYNC mode opens, 
without the necessity for locking, and so on. 
1003.1-1988 is silent on the issue; the 
proposed fix from TFA (basically a 
compromise I did not like and knew would 
fail) was that read-after-write be guaranteed 
only for co-located processes and in the pres¬ 
ence of locking. This gave 1003.1 a chance to 
avoid relaxing their intended semantics while 
leaving TFA a “loophole” to change semantics 
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without having to indicate a change in wording 
from 1003.1. 

This is what got rejected by 1003.1, which is 
getting pretty damned tired of TFA’s trying to 
claim that the full TFA semantics are “just 
like” 1003.1 but with gaping differences that 
are introduced silently due to weak or weasel 
wording in 1003.1-1988. 

3. 1003.7, System Administration, is making 
distressingly slow progress. If this continues, 
1003.8 will have two choices with respect to 
client-side administrative commands: 

• Do not standardize them; give feedback to 
1003.7 and wait for them to complete their 
specification. This risks incompatible imple¬ 
mentations. 

• Standardize them insofar as they relate to 
TFA administration. This risks incompatibil¬ 
ity between the TFA aspects of those com¬ 
mands and their more general aspects. An 
example is the mount command; if 1003.7 is 
unhappy with the form of the TFA mount 
command, they are under no constraint to 
remain compatible with it. If the group ballots 
far enough in advance of 1003.7, this sort of 
clash could be frequent. 

4. Many of the contentious issues have been 
“resolved” through the various mechanisms 
POSIX provides for introducing optional 
behavior; most frequently, these involve either 
“implementation-defined” behavior, or the 
addition of path-specific attributes whose 
status can be determined through the path- 
confQ function. Several of these options 
should be viewed by the ballot group as being 
“gratuitous” in some sense; i.e., the TFA com¬ 
mittee should take a stand one way or another, 
and be willing to be beaten up in ballot for it. 
The POSIX standards are wishy-washy enough 
without the addition of gratuitous options. 

Report on IEEE 1201: User Interface 

Eileen Coons <coons@osf.org> reports on the 
October 16-19, 1989 meeting in Brussels, Bel¬ 
gium: 


“The time has come,” the walrus said, 

“To talk of many things: 

Of shoes - and ships - and sealing wax - 

Of cabbages - and kings - 
And why the sea is boiling hot - 

And whether pigs have wings.” 

- Lewis Carroll 

The PI201 committee is on a divine mis¬ 
sion to define standards for user interface 
technologies. Lewis Carroll would have loved 
PI 201 meetings. 

In keeping with the precedent set by previ¬ 
ous PI201 meetings, this latest get-together 
was spirited. The quasi-good news is that, by 
the end of the session, not one, but three 
PARs had been defined, as the group split into 

1201.1 (Application Programming Interface), 

1201.2 (Drivability - Look & Feel), and 1201.3 
(User Interface Definition Language). One 
participant aptly named the proceedings “PAR 
Wars.” 

There was agonized discussion over the 
various sub-groups’ missions, and an equal 
amount of agonized, and at times agonizing, 
wordsmithing over the .1 and .2 PARs them¬ 
selves. The .3 group thoughtfully elected to 
split off and define itself in private. The PARs 
will be submitted via proper official channels 
to be blessed at the January SEC meeting. 

For anyone not familiar with the PAR 
process, PAR is an acronym for Project 
Authorization Request. An individual or 
group that believes some work should be done 
by an IEEE committee drafts a document 
describing the work, which is then submitted 
to the IEEE as a PAR. Usually the PAR is cir¬ 
culated to the IEEE membership. 

The Standards Executive Committee 
(SEC) reviews the PAR during its next 
scheduled session, typically held during a 
POSIX meeting. The SEC votes on the PAR, 
and if it is approved by the SEC, it is 
presented to Technical Committee on Operat¬ 
ing Systems (TCOS). TCOS decides in which 
committee the work will be done. In the case 
of the PAR for User Interface, TCOS elected 
to divorce the work from the core POSIX 
effort (1003), and created P1201. 
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The PAR becomes part of the statement 
of work and basic charter for the group doing 
the work. 

Fortunately, at this meeting, the group 
finally created some real structure for itself. 
The group decided to define an agenda and 
resolved that all meeting attendees should 
receive minutes of the meeting. Jim Isaak, the 
chair of the 1003 SEC, helped with structural 
definition by supplying IEEE rules and charter 
information, explaining the balloting process, 
and listing action options open to the com¬ 
mittee. 

Seven ballot alternatives were proposed, 
ranging from submitting a proposal for 
immediate ballot, to disbanding 1201. A vote 
was called, and although there was no con¬ 
sensus the heavy favorite was a proposal to 
adopt Motifs API as the basis for a standard 
API specification, and to extend it to accom¬ 
modate aspects of Open Look’s style. 

This general direction was unpopular with 
a vocal minority, and so the group discarded 
the vote and returned to its original, pre-poll 
path of action: defining a specification for an 
API based on neither Motif nor Open Look, 
but on some new API - probably a hybrid of 
the two. 

[Editor’s note: I’ve heard more than one 
person express ill-ease about the restricted 
range of choices being considered. Why is 
there no mention of NeXT/Step, for example? 
A noticeable feeling among people who aren’t 
on the committee is that it’s too early to try to 
standardize in this area, and that the answer to 
the question, “Motif or Open Look?” should 
be, “No thanks.” The answer to the implied 
question, “Why is there a PI201 and why are 


we doing this now, anyway?” seems to be that 
NIST, the National Institute for Standards and 
Technology (the people who bring you FIPS), 
is pushing hard for rapid creation of a GUI 
standard.] 

Two presentations were made: one by 
AT&T, in favor of the joint API concept, and 
one by OSF, arguing against its feasibility. 
This was followed by a critique of - some 
thought, attack on - the second presentation 
by one of the acting chairs, Clive Feather of 
X/OPEN. PI201 may be many things but, so 
far, staid isn’t one of them... 

On a more neutral note, several represen¬ 
tatives from organizations working on UIDL 
technologies made presentations about what 
they were doing in that arena, and then went 
off to form PI201.3. 

The rest of the group broke into the .1 
and .2 sub-groups for working sessions during 
most of the remaining meeting time. Each 
group reviewed its newly drafted PAR. 
PI201.1 also spent time comparing Motif and 
Open Look, identifying and exploring the 
differences between the two API’s, and looking 
for potential drivability issues that could be 
deferred to P1003.2. P1003.2 took a similar 
course of action, comparing the styles of the 
two technologies. 

There was also a spirited discussion 
regarding when and where the next PI201 
meetings should be held. After various alter¬ 
natives were explored, the group decided to 
keep PI201 meetings in the same vicinity and 
timeframe as POSIX meetings, since many 
attendees need, or want, to participate in 
POSIX as well. 
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Local User Groups 

The Association will support local user groups by doing a mailing to assist the formation of a 
new group and publishing information on local groups in ;login At least one member of the group 
must be a current member of the Association. Send additions and corrections to login@usenix.org . 


CA - Fresno: the Central California UNIX Users 
Group consists of a uucp-based electronic mailing 
list to which members may post questions or infor¬ 
mation. For connection information: 

Educational and governmental institutions: 

Brent Auemheimer (209) 294-4373 

brent@CSUFresno.edu or csufreslbrent 

Commercial institutions or individuals: 

Gordon Crumal (209) 875-8755 

csufreslgordon (209) 298-8393 


CO - Boulder: the Front Range UNIX Users Group 
meets monthly at different sites. 

Steve Gaede 

636 Arapahoe Ave., #10 

Boulder, CO 80302 

(303) 447-8586 

FL - Coral Springs: 


S. Shaw McQuinn 

8557 W. Sample Road 

Coral Springs, FL 33065 

(305) 344-8686 

FL - Fort Lauderdale/Miami: The South Florida 
UNIX Users Group meets the 2 nd Tuesday of each 
month. 

Tony Vincent, John McLaughlin 
{sun,novavax,gould) !sunvice!tony 
jmclaughlin@sun.COM 

(305) 776-7770 

John O’Brien 

gatech!uflorida!novavax!john 

(305) 475-7633 

Don Joslyn 

gatech!uflorida!novavax!rm 1 !don 

(305) 476-6415 

FL - Jacksonville/Northeast: UNIX Users of Jack¬ 
sonville (uujax) meets the 2 nd Thursday of each 
month. 

Tom Blakely 
uflorida!unf7!tfb 

(904) 646-2820 

Emilie Olsen 

(904) 390-3621 

FL - Melbourne: the Space Coast UNIX Users 
Group meets at 8pm on the 3 rd Wednesday of each 
month at the Florida Institute of Technology. 

Bill Davis 
bill@ccd.harris.com 

(407) 242-4449 


FL - Orlando: the Central Florida UNIX Users 

Group meets the 3 rd Thursday of each month. 

Mike Geldner (305) 862-0949 

codas!sunfla!mike 

Ben Goldfarb (305) 275-2790 

goldfarb@hcx9.ucf.edu 

Mikel Manitius (305) 869-2462 

{codas,attmail) Imikel 

FL - Tampa Bay: the Tampa UNIX Users Group 
meets the 1 st Thursday of each month in Largo. 

Bill Hargen (813) 530-8655 

uunet!pdn!hargen 

George W. Leach (813) 530-2376 

uunet!pdn!reggie 

GA - Atlanta: meets on the 1 st Monday of each 
month in White Hall, Emory University. 

Atlanta UNIX Users Group 
P.O. Box 12241 
Atlanta, GA 30355-2241 

Marc Merlin (404) 442-4772 

Mark Landry (404) 365-8108 

MI - Detroit/Ann Arbor: The SouthEastem 

Michigan Sun Local Users Group meets jointly with 
the Nameless UNIX Group on the 2 nd Thursday of 
each month in Ann Arbor. 

Steve Simmons home: (313) 426-8981 

scs@lokkur.dexter.mi.us office: (313) 769-4086 

K. Richard McGill 
rich@sendai.ann-arbor.mi.us 

Bill Bulley 
web@applga. uucp 

MI - Detroit/Ann Arbor: dinner meetings the 1 st 
Wednesday of each month. 

Linda Mason (313) 855-4220 

michigan!/usr/group 

P.O. Box 189602 

Farmington Hills, MI 48018-9602 
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MN - Minneapolis/St. Paul: meets the 1 st Wednes¬ 
day of each month. 

UNIX Users of Minnesota 
17130 Jordan Court 
Lakeville, MN 55044 


Robert A. Monio 
pnessutt@nis.mn.org 

(612) 895-7007 

MO - St. Louis: 

St. Louis UNIX Users Group 

Plus Five Computer Services 

765 Westwood, 10A 

Clayton, MO 63105 


Eric Kiebler 
plus5!sluug 

(314) 725-9492 

NE - Omaha: meets the 2 nd 
month. 

/usr/group nebraska 

P.O. Box 44112 

Omaha, NE 68144 

Thursday of each 

Kent Landfield 
kent@ugn.uucp 

(402) 291-8300 

New England - Northern: meets monthly at differ¬ 
ent sites. 

Peter Schmitt 

Kiewit Computation Center 
Dartmouth College 

Hanover, NH 03755 

(603) 646-2999 

decvaxldartvaxlnneuug-contact 


NJ - Princeton: the Princeton UNIX Users Group 
meets monthly. 

Pat Parseghian 

Dept, of Computer Science 
Princeton University 

Princeton, NJ 08544 

pep@Princeton.EDU 

(609) 452-6261 


NY - New York City: 

Unigroup of New York 
G.P.O. Box 1931 
New York, NY 10116 

Ed Taylor (212) 513-7777 

{attunix,philabs)!pencom!taylor 


OK - Tulsa: the Tulsa UNIX Users Group, $USR, 
meets the 2nd Wednesday of each month. 

Stan Mason (918) 560-5329 

tulsix!smason@drd.com 


Mark Lawrence (918) 743-3013 

mark@drd.com 

PA - Philadelphia: the UNIX SIG of the Philadel¬ 
phia Area Computer Society (PACS) meets the 
morning of the 3rd Saturday of each month. 

G. Baun, UNIX SIG 
c/o PACS 
Box 312 

La Salle University 
Philadelphia, PA 19141 

rutgers! {bpa,cbmvax}! 

temvaxlpacsbb! {gbaun,whutchi} 

TX - DaUas/Fort Worth: 

Dallas/Fort Worth UNIX Users Group 
Seny Systems, Inc. 

5327 N. Central, #320 
Dallas, TX 75205 

Jim Hummel (214) 522-2324 

TX - Houston: the Houston UNIX Users Group 
(Hounix) meets the 3 rd Tuesday of each month. 

Hounix answering machine (713) 684-6590 

Bob Marcum, president (713) 270-8124 

Chuck Bentley, vice-president (713) 789-8928 

chuckb@hounix.uucp 

TX - San Antonio: the San Antonio UNIX Users 
(SATUU) meets the 3 rd Thursday of each month. 

Jeff Mason (512) 494-9336 

Hewlett Packard 

14100 San Pedro 

San Antonio, TX 78232 

gatech!petro!hpsatb!jeff 

WA - Seattle: meets monthly. 

Bill Campbell (206) 232-4164 

Seattle UNIX Group Membership Information 
6641 East Mercer Way 
Mercer Island, WA 98040 

uw-beaver!tikal!camco!bill 

Washington, D.C.: meets the l sl Tuesday of each 
month. 

Washington Area UNIX Users Group 
2070 Chain Bridge Road, Suite 333 
Vienna, VA 22180 

Samuel Samalin (703) 448-1908 


January/February 1990 


47 



USENIX Association 
2560 Ninth Street, Suite 215 
Berkeley, CA 94710 


First Class Mail 


FIRST CLASS MAIL 
U.S. POSTAGE PAID 
Hayward, CA 
Permit No. 2 
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Professional Development Seminars 
Speakers Bureau 

Book Reviews and much, much more .... 
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